Communication node and packet transfer method

ABSTRACT

A communication node which can reliably transfer a packet with a payload including data having error resistance in radio environments is disclosed. A packet to be transmitted is divided into segments to form a plurality of packet segments. From among a plurality of error correction schemes that have been prepared in advance, the scheme to be employed is selected for each of the packet segments in accordance with predetermined criteria, and the selected error correction scheme is applied to each packet segment. Subsequently, the processed packet segment is transmitted to the network. Packet segments are received from the network. From among a plurality of error correction schemes prepared in advance, the scheme to be employed is selected for each of the received packet segments based on predetermined information contained in each received packet segment, and the selected error correction scheme is applied to the received packet segment. An original packet is formed from the plurality of processed packet segments.

CROSS REFERENCE TO RELATED APPLICATION

This application claims benefit of priority to Japanese PatentApplication No. P10-249859 filed Sep. 3, 1998, the entire disclosure ofwhich is incorporated by reference herein.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a communication node and a packettransfer method for transferring a segmented packet, and moreparticularly to a communication node and a packet transfer method fortransferring a packet over a radio network which is a part of globalpacket-switched network (e.g., Internet).

2. Description of the Background

Recently, demand for radio communications has experienced an explosiveincrease. An infrastructure for radio communications, represented bycellular phones and PHS (Personal Handy Phone system), has beenconstructed at a drastically increased pace in recent years. Not onlyhas voice communications been the focus of attention, datacommunications has attracted significant interest in the form of theInternet.

Future trends of communications networks include (1) a further increasein capacity of communications networks, (2) more widespread use of theso-called multimedia communications in which audio, video, data, etc.are integrated, and (3) an increase in Internet applications as well asmore widespread use of the Internet.

Examples of the first trend include next-generation cellular phones(e.g., IMT-2000) and radio ATM networks. Standardization of radio ATMnetworks has been championed by MMAC. Examples of the second trendinclude standards (such as H.324) for TV phones. Examples of the thirdtrend include the World Wide Web (WWW), Internet telephony,video-on-demand on the Internet, etc.

It should be noted that the above trends are not independent of oneanother, but will progress in a closely correlated fashion. For example,TV phones will be able to be implemented as an Internet application, anda radio infrastructure providing Internet services, etc. will emerge.

Key factors in enabling the construction of an infrastructure to supportsuch applications as TV phones on the Internet in a mobile environment,include video/audio coding techniques (e.g., MPEG4), and real-timeInternet protocols (e.g., RTP (Real-Time Transport Protocol)). MPEG4provides coding of video and audio information in a network environmentwhere bandwidth constraints are a major concern, such as phone lines andradio lines, by utilizing a highly efficient coding technique. From aprotocol perspective, RTP is useful in operating video and audioapplications in a network infrastructure where packets are susceptibleto omission and delay, such as the Internet. A combination of thesetechniques (e.g., MPEG4 over RTP) is expected to realize in thebandwidth constrained Internet multimedia communication.

However, the following problem arises in realizing such Internetmultimedia communication. When transmitting video and audio inaccordance with MPEG4 in the radio environment, the efficiency of thecoding scheme and the error resistance provide the capability to decodethe video/audio with acceptable quality to the users, even if some datais omitted or arrives with bit errors during the transmission. In thecase of where MPEG4 video/audio data is transmitted as Internet packetsin a radio environment, the MPEG4 portion is resistant to errors, butthe header portion (that is referred to and used by the network), suchas the IP header and the UDP header, has no error resistance capability.If a bit error occurs in the header portion, the Internet packetincluding such a bit error must be discarded.

As described above, when a packet with a payload that includes datahaving certain burst error resistance and bit error resistance (e.g.,MPEG4 video/audio) is transmitted in the radio environment, the entirepacket must be discarded if a bit error occurs in the header portion ofthe packet. This is problematic because the packet is unnecessarilydiscarded if the payload can recover lost data, resulting in reducedsystem throughput.

SUMMARY OF THE INVENTION

In view of the situations set forth above, an object of the presentinvention is to provide a communication node and a packet transfermethod which can reliably transfer a packet with a payload includingdata having error resistance in radio environments.

A communication node according to a first aspect of the presentinvention comprises means for dividing a packet to be transmitted intosegments to form a plurality of packet segments; means for selecting anerror correction scheme from among a plurality of error correctionschemes prepared in advance to be employed for each of the packetsegments in accordance with predetermined criteria; means for carryingout an error correction procession each packet segment with the selectederror correction scheme; and means for transmitting each processedpacket segment to a network.

A communication node according to a second aspect of the presentinvention comprises means for receiving packet segments from a network;means for selecting an error correction scheme from among a plurality oferror correction schemes prepared in advance to be employed for each ofthe received packet segments based on predetermined informationcontained in each received packet segment; means for carrying out anerror correction process on each received packet segment with theselected error correction scheme; and means for forming an originalpacket from the plurality of processed packet segments.

With the above features of the present invention, by way of example,when a header portion and a payload portion of a packet to betransmitted have different error resistance characteristics, the packetcan be transmitted to a network under selection of error correctionschemes suitable for the respective error resistance characteristics.

Preferably, the communication node may further comprise means fornegotiating correspondence relations between predetermined informationcontained in the packet segments and error correction schemes to beemployed for the packet segments containing the predeterminedinformation, prior to transferring the plurality of packet segmentsbetween the communication node and another communication node oppositeto each other via the network. In other words, the communication nodeincludes a means for negotiating with another communication node that isconnected to the network, prior to transferring the plurality of packetsegments, the error correction scheme to be employed in relation toparticular packet segments.

With the above features, the communication node on the packettransmitting side and the communication node on the packet receivingside can negotiate in advance as to what types of error correctionschemes are used in communications.

Therefore, both the communication nodes can mutually agree about theerror correction schemes to be used, and operate in synchronizedrelation based on the agreement.

Preferably, in the communication node on the packet transmitting side,the plurality of packet segments each may have a field describingtherein information based on which the error correction scheme to beemployed is selected, and the communication node may further comprisemeans for describing, in the field, the information corresponding to theselected error correction scheme.

With the above features, the communication node on the receiving sidecan recognize what type of error correction scheme is to be used todecode the received packet segment.

Preferably, in the communication node on the packet receiving side, theplurality of packet segments each may have a field describing thereininformation based on which the error correction scheme to be employed isselected, and the selecting means may select the error correction schemeto be employed based on the information described in the field.

With the above features, the communication node on the receiving sidecan recognize what type of error correction scheme is to be used todecode the received packet segment.

Preferably, the plurality of packet segments each may have a fielddescribing therein information based on which the error correctionscheme to be employed is selected, and the communication node mayfurther comprise means for, prior to transferring the plurality ofpacket segments between the communication node and another communicationnode opposite to each other via the network, negotiating correspondencerelations between the contents of information described in the field anderror correction schemes to be employed.

With the above features, the communication node on the packettransmitting side and the communication node on the packet receivingside can negotiate in advance as to what types of error correctionschemes are used in communications and values set in the fieldcorresponding to the error correction schemes. Therefore, both thecommunication nodes can mutually agree about the error correctionschemes to be used, and operate in synchronized relation based on theagreement.

Preferably, an error correction scheme employed for a particular one ofthe packet segment may have a higher correction ability than an errorcorrection scheme employed for the other packet segments. In this case,preferably, the particular packet segment may be a packet segmentincluding a header portion of the packet.

With the above features, since the header portion of a packet, forexample, generally does not have error resistance, the header portioncan be given a strong error correction ability. It is therefore possibleto reduce a probability of the occurrence of errors in the packet headerportion during radio transmission, and to avoid the packet from beingdiscarded in a packet header processing unit in the communication node.

Preferably, the error correction scheme to be employed for the packetsegments contained in the packet may be decided by referring to a valuein a higher-level protocol field of the packet. Preferably, the errorcorrection scheme to be employed for the packet segments contained inthe packet may be decided by referring to a value of the port number inthe packet.

With the above features, the error correction scheme can be flexiblyselected in match with a higher-level protocol characteristic, forexample, such that a strong error correction scheme is employed for apacket for which reliable communication is not expected with thetransport layer, e.g., a UDP packet in the Internet, and a weak errorcorrection scheme is employed for a packet for which reliablecommunication is expected with the transport layer, e.g., a TCP packet.

A packet transferring method according to a third aspect of the presentinvention comprises the steps of dividing a packet to be transmittedinto segments to form a plurality of packet segments; from among aplurality of error correction schemes prepared in advance, selecting thescheme to be employed for each of the packet segments in accordance withpredetermined criteria; carrying out an error correction process on eachpacket segment with the selected error correction scheme; transmittingeach processed packet segment to a network; receiving packet segmentsfrom a network; from among a plurality of error correction schemesprepared in advance, selecting the scheme to be employed for each of thereceived packet segments based on predetermined information contained ineach received packet segment, carrying out an error correction processon each received packet segment with the selected error correctionscheme; and forming an original packet from the plurality of processedpacket segments.

It is to be noted that the present invention relating to the apparatusis also effectuated as the invention relating to the method, andconversely the present invention relating to the method is alsoeffectuated as the invention relating to the apparatus.

Further, the present invention relating to the apparatus or the methodcan also be effectuated in the form of a computer-readable recordingmedium which records thereon a program for rendering a computer toexecute procedures equivalent to the means or steps in the presentinvention (or rendering a computer to function as means equivalent tothat in the present invention, or rendering a computer to realizefunctions equivalent to those in the present invention).

With the present invention, when a header portion and a payload portionof a packet to be transmitted have different error resistancecharacteristics, the packet can be transmitted to a network underselection of error correction schemes suitable for the respective errorresistance characteristics.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete appreciation of the invention and many of the attendantadvantages thereof will be readily obtained as the same becomes betterunderstood by reference to the following detailed description whenconsidered in connection with the accompanying drawings, wherein:

FIG. 1 shows one example of an entire configuration of a network systemaccording co a first embodiment of the present invention;

FIG. 2 shows one example of an overall layer configuration;

FIG. 3 shows one example of a transfer packet format;

FIG. 4 shows one example of an internal configuration of a terminal;

FIG. 5 shows one example of a frame transmission format on a radiotransmission path;

FIG. 6 shows one example of an entire sequence;

FIG. 7 shows one example of an MC table;

FIG. 8 shows one example of an FEC table;

FIG. 9 is a diagram showing a process of transforming an MPEG4 packetinto an H.223 mobile frame;

FIG. 10 is a diagram showing a process of transforming a general IPpacket into an H.223 mobile frame;

FIG. 11 is a diagram illustrating a process of transforming a general IPpacket into an H.223 mobile frame;

FIG. 12 shows one example of a flow/error control correspondence table;

FIG. 13 shows one example of a frame transmission format on a radiotransmission path in a second embodiment of the present invention;

FIG. 14 shows one example of an entire sequence;

FIG. 15 shows one example of an MC table;

FIG. 16 is a diagram for explaining a process of transforming an MPEG4packet into an H.223 mobile frame; and

FIG. 17 is a diagram for explaining a process of transforming a generalIP packet into an H.223 mobile frame.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Referring now to the drawings, wherein like reference numerals designateidentical or corresponding parts throughout the several views.

FIG. 1 shows one example of an overall configuration of a network systemaccording to a first embodiment of the present invention.

Referring to FIG. 1, a terminal 107 communicates with a WWW server 101via a radio transmission path 106, such as a radio public network. Here,the WWW server 101, an access router 103, and the terminal 107 are nodesthat are connected to the Internet 102.

In the Internet communication system shown in FIG. 1, transmission pathsbetween the access router 103 and the terminal 107 (i.e., a wiredtransmission path 104 and the radio transmission path 106) areconsidered part of the Internet 102, beyond just the wired network.However, for purposes of explanation, the transmission paths 104 and 105are considered separate from the Internet 102 to highlight the presentinvention, which focuses on the differences in transmission properties(e.g., a transmission error) between those transmission paths 104 and105 and the Internet 102.

The terminal 107 securely establishes a connection to the access router103 via the wired transmission path 104. In fact, radio station 105 ispositioned between the access router 103 and the terminal 107.Specifically, radio station 105 is interposed between the wiredtransmission path 104 and the radio transmission path 106.

At the physical layer, the radio station 105 carries out processing suchas transmission medium conversion. Processing for the link layer iscarried out between the access router 103 and the terminal 107. In otherwords, the radio station 105 does not take part in processing for layershigher than the link layer.

In an exemplary embodiment, it is assumed that the radio transmissionpath 106 is a PHS (Personal Handy Phone system)—which is a radio publicnetwork. It is apparent that the present invention is not limited to thePHS network, but also applicable to any types of radio access networkenvironments, such as a cellular phone network, a radio local loop, IMT2000 (W-CDMA network), or a next-generation radio access network. Thepresent invention is also applicable to non-public networks.

The protocol architecture as well as the network architecture, inaccordance with one embodiment, is described below.

This embodiment provides, as described above, Internet communicationbetween terminal 107 and WWW server 101. One important application overthe Internet 102 is real-time video/audio communications. Real-timevideo/audio communication is carried out, utilizing a coding techniquewith high “error resistance”. By way of example, the real-timevideo/audio communication is MPEG4 video and/or MPEG4 audio over theInternet 102 (including communications of only MPEG4 video,communications of only UNPEGS audio, and communications of both MPEG4video and MPEG4 audio).

FIG. 2 shows one example of the protocol layers involved in thecommunication between the terminal 107 and the WWW server 101. Thoselayers higher than the transport protocol (i.e., layers higher thanTCP/UDP) are usually not terminated in a router (the access router 103in FIG. 1) within the Internet 102. That is, in the networkconfiguration of FIG. 1, protocol stacks for layers higher than thetransport layer are present only in the WWW server 101 and the terminal107.

Since packet transfer is carried out in the form of an IP (InternetProtocol) packet, IP is employed as the network layer protocol. IP layerprocessing is performed not only in the WWW server 101 and the terminal107, but also in the access router 103, which relays the IP packet.Although only the access router 103 is shown in FIG. 1, numerous routersexist within the Internet 102. In this case, IP layer processing isperformed in every router.

In addition to transferring real-time video/audio information withinpackets, as in the exemplary embodiment, the packet may include dataother than real-time video/audio information, such as a controlinformation, etc.

As for the link layer protocol, H.223 mobile standard is employedbetween the access router 103 and the terminal 107, according to oneembodiment. By operating the H.223 protocol between the access router103 and the terminal 107, these devices 103 and 107 are provided with acertain level of reliability. The details of H.223 will be describedlater.

Link layer protocols between the WWW server 101 and the access router103 are assumed to be link layer standards Y and X for convenience(i.e., the link layer standard of a link associated with the WWW server101 is Y and the link layer standard of a link associated with theInternet 102 side of the access router 103 is X).

As shown in FIGS. 1 and 2, the WWW server 101 communicates with theradio station 105 via a wired transmission network, while the radiostation 105 communicates with the terminal 107 over a radio transmissionnetwork. At the physical layer, therefore, the radio station 105performs a transmission medium transfer process between the wired andradio networks.

Packet format will be described next.

FIG. 3 shows one example of a packet format, which contains MPEG4 video.As indicated above, such a packet is transferred between the accessrouter 103 and the-terminal 107 using the described protocolenvironments. In accordance with the protocol stack shown in FIG. 2, anMPEG4 video 301 is capsulated in a system header 302 containing timestamp information, inter-media synch information, etc. Then, an RTPheader 303, a UDP header 304, and an IP header 305 are added to thesystem header successively in the respective order. Finally, a PPP(Point-to-Point Protocol) header (306) is added.

It is sufficient for the PPP header to contain protocol identificationdata to identify protocol types such as IPv4 and IPv6. The packet headercan be detected by using the H.223 as the link layer protocol;consequently, using a field that solemn changes is inefficient. For thisreason, a flag sequence field (for detecting the packet boundary), anaddress field (containing always the same value), and a control field(containing always the same value), which are used in PPP of RFC 1661,are not needed.

Note that detection of the packet boundary (i.e., detection of a headerfragment in a packet) can also be performed using a value of the linklayer header (specifically a value of the MUX code (MC)). This approachis more fully described later.

FIG. 4 shows one example of an internal configuration of the terminal107 according to an embodiment of the present invention. As shown inFIG. 4, the terminal 107 comprises an H.223 mobile processing unit 1101,which performs the processing related to the H.223 mobile serving as thelink layer protocol. The terminal 107 also comprises an IP/PPPprocessing unit 1102 for carrying out the processing related to IF andPap, and a TCP processing unit 1103 for carrying out the processingrelated to TCP. Further, the terminal 107 includes a UDP processing unit1104 for carrying out the processing related to UDP, and an RTPprocessing unit 1105 for carrying out the processing related to RTP(Real-time Transport Protocol). A system/multiplex processing unit 1106is included in the terminal 107 for carrying out such processing asadding control information (e.g, time stamp information and inter-mediasynch information), which is necessary in the MPEG4 application, to thecoded audio/video data in a transmission mode. The system/multiplexprocessing unit 1106 also interprets the control information and startsup the decoding process in reception mode. The terminal 107 alsocomprises an MPEG4 audio processing unit 1107 for carrying out codingand decoding of the MPEG4 audio data, and an MPEG4 video processing unit1108 for carrying out coding and decoding of the MPEG4 video data. TheH.223 mobile processing unit 1101 comprises the following components: afragment processing unit 1111 for dividing a packet into fragments, aframe processing unit 1112 for setting the fragments on a frame; an FECtable 1113 for storing the correspondence between FEC codes in the frameand FEC types used; an MC table 1114 for storing the correspondencebetween MC codes in the frame and data identification information,attributes, etc.; an H.245 processing unit 1115 for carrying out theprocessing related to an H.245 protocol; and a radio interface unit 1116for carrying out the interface processing with respect to the radionetwork. Additionally, a radio transmitter/receiver may be built in theterminal 107 or connected to the terminal 107 externally—e.g., a PHSterminal. As described later, the frame processing unit 1112 may includea flow/error control correspondence table 1117 for storing thecorrespondence between predetermined packet attributes and to be addedMC codes. It should be noted that functions of inputting (or composingor editing) data to be coded and transmitted, and functions ofoutputting (or recording, displaying or reproducing) data received anddecoded are omitted.

The construction and operation of the terminal 107 will be describedbelow in connection with, by way of example, placing video and audiothat are encoded in accordance with MPEG4 or the like, in an IP packet;in particular, the case in which the terminal 107 is on the transmissionside. First, MPEG4 data is decoded in the MPEG4 video processing unit1108 and/or the MPEG4 audio processing unit 1107. The system/multiplexprocessing unit 1106 adds control information (e.g., time stampinformation and inter-media synch information) to the coded data. Theheader added here is referred to as the system header (302 in FIG. 3).

The RTP processing unit 1105 encapsulates the added data with the systemheader. RTP is a de facto standard of the transport protocol fortransferring traffic of a real-time application on the premise that datadelivery is delayed or lost in the Internet, etc. Usually, RTP isemployed in combination with RTCP (Real-time Transport Control Protocol)for exchanging packets in the network, etc. between the transmittingside and the receiving side. Details of RTP are explained in RFC 1889and 1890.

Thereafter, the RTP is set on UDP (User Datagram Protocol) in the UDPprocessing unit 1104, converted into an IP packet in the TP/PPPprocessing unit 1102, and then transferred as an Internet packet (seeFIG. 3) over the Internet 102 including the radio transmission path 106.As described later, the Internet packet is transferred over the radiotransmission path in such a manner that it is divided into segments inthe H.223 mobile processing unit 1101 and set on a frame.

The H.223 mobile will now be described.

The packet shown in FIG. 3 is transferred between the access router 103and the terminal 107 in accordance with H.223 (see FIG. 2), which is alink layer protocol. The H.223 mobile processing unit 1101 carries outthe processing necessary for the packet transfer.

FIG. 5 shows one example of a frame transmission format on the radiotransmission path 106. As shown in FIG. 5, one frame transfers 0 to 254bytes of data. One frame consists of the data, a 16-bit P.N., a MUS code(MC), a MUX-POW length (MEL), a Golay parity code, a header comprisingan FEC type code, and a trailer comprising 16-bit P.N. The frame isconstructed primarily by the frame processing unit 1112. Numeralsindicated in FIG. 5 above respective areas denote, by way of example,the number of bits contained in the areas.

Synchronization of the packet (i.e., detection of the head and tail ofthe packet) is performed using two sets of 16-bit PN and M.L.Specifically, the two sets of 16-bit PN are each constructed as apredetermined pattern and are always positioned at the head and tail ofthe packet, respectively. If such a pattern is detected, it isrecognized that the detected point is a candidate for the boundary ofthe frame. Thereafter, the area of M.L. is checked.

After recognizing the length of the relevant frame in the area of MPL,the other 16 bits are checked in consideration of the data areacorresponding to the M.L. length. If an area of the 16-bit PN is foundagain, it is determined that the frame is correctly synchronized.

The MUX code represents the attributes of the data transferred. The FEWcode represents the attributes of a forward error correction codeapplied to the data The MUS code and the FEC code are each simply givenas a numerical value. Prior to the start of communication, the meaningsof the respective numerical values are negotiated beforehand betweenboth terminals, which will then communicate using H.235.

FIG. 6 shows one example of the negotiation process between the accessrouter 103 and the terminal 107. The H.245 protocol is used in thenegotiation. The negotiation process is executed by the H.245 processingunit 1115 in the H223 mobile processing unit 1101. In this embodiment,as shown in FIG. 6, the meanings of respective numeral values of the MCcode and the FEC code are negotiated between the access router 103 andthe terminal 107. Results of the negotiation related to the MC code andthe FEC code are reflected in the MC table 1114 (see FIG. 7) and the EECtable 1113 (see FIG. 8). These two tables are held in both nodes, i.e.,the access router 103 and the terminal 107.

FIG. 7 shows one example of the MC table 1114, and FIG. 8 shows oneexample of the FEC table 1113. It is negotiated, for example, that inthe case of MC=1 and MC=2, data having different attributes (DATA 1 forMC═I and DATA 2 for MC=2) are communicated, and that in the case ofMC=1, FEC1 is used as the FEC scheme if the FEC code=1 holds and FEC2 isused as the FEC scheme if the FEC code=2 holds. The results are thenreflected in the tables as shown in FIGS. 7 and 8.

Thus, the FEC table may be defined for each MUS code, in which thevalues of the FEC code may have different meanings for each MUS code, asillustrated in FIG. 8. It should be noted that the FEC table may bedefined regardless of the MUS code.

Use of error correction schemes with different levels will be describednext.

In this embodiment, the MPEG4 video/audio is transmitted over, by way ofexample, the Internet 102. The MPEG4 is a coding technique that has veryhigh “error resistance” because it was developed in anticipation of avery poor communications network environment (i.e., network environmentwhere data is susceptible to large bit error rate, burst error, oromission); for example, a radio transmission path 106 and the Internet102. Also, MPEG4 permits communication at a very low bit rate toaccommodate low bandwidth media, such as phone lines and radio lines, ascompared to Ethernet LAN or the like.

In the present invention, it is believed that when the contents of apacket payload have strong error resistance, such as MPEG4, the payloadhas a certain level of resistance against errors caused by packetomissions on the Internet and bit errors from radio section of thetransmission path.

As shown in FIG. 3, various headers (i.e., the system header, the RTPheader, the UDP header, the IP header and the PPP header) are added tothe transferred packet in addition to the MPEG4 video/audio. If theheader portion is subject to an error of even one bit in the radiotransmission region, for example, this gives rise to a fatal error thatis not tolerated by the terminal on the receiving side. The error in theheader could result in erroneous information, such as a change of thedestination/source address/port numbers and “change of value of the timestamp”.

Even though the payload was prepared using a coding technique with higherror resistance like MPEG4, if an error occurs in the header, thepacket is discarded before reaching an MPEG processing module of a node,such as a terminal (the MPEG4 audio processing unit 1107 or the MPEG4video processing unit 1108 in FIG. 4). For example, if an error of evena single bit occurs in the IP process that is executed in the IP/PPPprocessing unit 1102, the relevant packet is discarded.

To overcome such a problem, it is contemplated that a strong errorcorrection code is applied to the header group (302-306) in FIG. 3 whena packet containing data with high error resistance, such as MPEG4video/audio, is transmitted over the radio transmission path. However,for a payload (e.g., portion of the MPEG4 video 301) that has high errorresistance originally, a strong error correction code is not required.It is sufficient to reduce the error rate on the radio transmission path106 to match the error resistance of MPEG4. In other words, whentransferring the packet shown in FIG. 3, error correction codes havingdifferent levels of strength are applied to the header portion (302-306)and the payload portion 301.

Assuming, for example, that a bit error rate in the radio transmissionpath (106 in FIG. 1) of 10⁻³ does not pose problems in reproducing dataand the error resistance of MPEG4 corresponds to a bit error rate on theorder of 10⁻⁶, the error correction code (e.g., FEC1) applied to theheader portion is selected to have a correction ability capable ofsubstantially completely correcting the error rate of 10⁻³ on the radiotransmission path. Also, the error correction code (e.g., FEW.) that isapplied to the payload portion, which is expected to have errorresistance (such as given by MPEG4), is selected to have a correctioncapability of reducing the error rate of 10⁻³ on the radio transmissionpath down to a limit value of the error resistance of MPEG4, i.e., theerror rate of 10⁻⁶.

In other words, in this embodiment, the strong error correction code(FEW.) is applied to the header portion (302-306) to substantiallycompletely remove errors generated on the radio transmission path 106.Further, the weak error correction code (FEC2) is applied to the payloadportion (portion of the MPEG4 video 301) so as to maintain the originalerror resistance of the MPEG4 video despite the fact that errors to someextent remain in the MPEG4 video portion.

Note that, in this embodiment, the check sum of UDP is assumed to beturned off.

Selecting the weak error correction code FEC2 is effective in reducingthe number of bits transmitted in radio communications and increasingthe transfer bit rate. Further, since the header portion is generallymuch smaller than the payload portion, the strong error correction codeFEC1 is applied to the header portion. In addition, the number ofredundant bits is not so increased.

Based on the above consideration, using an H.245 negotiation process (inFIG. 6), a strong error correction code FEC1 is employed for the headerportion in which any data error is not basically allowed, and the weakerror correction code PEC2 is employed for the MPEG4 video/audio portionin which some data error is tolerated. The FEW table shown in FIG. 8 isthen prepared to hold the contents of the negotiation results in theform of an internal table.

An example of transferring an MPEG4-over-IP packet is be described belowwith reference to FIG. 9.

A packet 801 (see FIG. 3), that is to be transferred, is divided intofragments having a size not larger than the link layer MT. (MaximumTransfer Unit)—i.e., the maximum value of a frame length transferablewith the link layer. This division into fragments is performed in thefragment processing unit 1111.

As a result of the fragmentation, the entire header portion (302-306 inFIG. 3) is included in a first fragment 802. In FIG. 9, the firstfragment 802 also includes a part of the MPEG4 video as well as theheader portion. The portion of the MPEG4 video is eventually dividedinto several segments (in the example of FIG. 9, the payload portion,i.e., the portion of the MPEG4 video 301, is divided into threefragments 802, 803 and 804). The fragments are then set on the frametransmission format for radio communications, shown in FIG. 5, in theframe processing unit 1112, and are transmitted through the radiointerface unit 116.

As shown at 805 in FIG. 8, the first fragment 802 is converted into aframe in accordance with H.223, whereby FEC. is employed as the errorcorrection code for the first fragment 802 because of the strong errorcorrection code capability of FEC. Accordingly, the value of the MUXcode is set to 1, and the value of the FEC code is set to 1 in theframe; thereafter, the frame is transmitted.

On the other hand, for the second and subsequent fragments 803 and 804,FEC2 is employed as the error correction code because a relatively weakerror correction code, which suppresses the error rate down to a levelcorresponding to the error resistance of MPEG4, is acceptable.Accordingly, the value of the MUX code is set to 1 and the value of theFEC code is set to 2 in the frame; thereafter, the frame is transmitted.

While the example of FIG. 9 has been described in connection with MPEG4data as the payload of the IP packet, the present invention hasapplicability to the transfer of to IP packets in general, regardless ofthe attributes of data that is contained in the payload. One example ofsuch a case will be described with reference to FIG. 10.

FIG. 10 shows one example of IP packets generally transferred, in whichTCP is employed as the transport protocol. In this scenario, as with thecase of FIG. 9, FEC. is employed as the error correction code for afirst fragment 902 because a strong error correction code should beapplied. On the other hand, second and subsequent fragments 903 and 904may be transferred using the relatively weak error correction code FEC2.

In the example of FIG. 10, the data contained in the payload of thepacket 901 generally does not always have error resistance. TCP carriesout error detection up to the IP header. Accordingly, the strong errorcorrection code FEC1 is applied to the first fragment 902, but the weakerror correction code FEC2 is applied to the subsequent fragments 903and 904. Therefore, if an error occurs in the fragments 903 and 904 andis not completely corrected by FEC2, such an error corrupts the datathat is received by the terminal 107 on the receiving side. However, ifan error occurs in segments 906 and 907 for any reason, the error isdetected by the CAC of TCP, and the whole of the relevant packet isretransmitted in the TCP layer. As a result, the packet is successfullydelivered.

There are two reasons why the strong error correction code FEC1 isapplied to the initial fragment 902. First, because the PPP header isexcluded from being subject to error correction by TCP, the use of FEC1reduces the probability of errors occurring in the PPP header. Secondly,in many cases of actual IP communications, error control is not appliedto the data in the header portion. Such is the case of transport layerprotocols other than TCP; e.g., IP phones using UDP as the transportprotocol. In those cases, various “error unallowable areas” (i.e., areaswhere if an error occurs, the system may malfunction, or the relevantpacket is discarded unconditionally regardless of the attributes of datain the payload), such as the IP header and the transport header, existsin the first fragment. Accordingly, applying the error correction codewith strong error correction ability to the first fragment is effective,in such cases.

The above description discussed the process of manipulating the packetwith respect to the transmitting side of the terminal 107. When theterminal 107 is on the receiving side, the process is basicallyperformed in a reversed manner.

Assuming the terminal 107 shown in FIG. 4 is to receive the packets, aframe received by the radio interface unit 1116 in the H.223 mobileprocessing unit 1101 is first subject to frame synchronization in theframe processing unit 1112. Next, necessary information is obtained fromthe MC code of the received frame by referring to the MC table 1114, andthe FEC scheme to be employed is selected by referring to the FEC table1113 based on the FEC code (or referring to the FEC table 1113 based onthe MC code and the FEC code when the contents of the FEC table 1113 aredefined for each MC code). The error correction code is then applied toeach frame. In the examples of FIGS. 7 and 8, when the MC code=1 and theFEC code=1 hold in the received frame, it is understood that the FECscheme to be employed is FEC. The frame for which the error correctionhas not been completely performed is discarded.

Having passed the error correction process, the fragments are taken outof the frame and transferred to the fragment processing unit 1111, wherethe fragments are assembled into a packet again. This packet is subjectto the PPP process and IP process in the IP/PPP processing unit 1102.After successively passing the UDP process in the UDP processing unit1104, the RTP process in the RTP processing unit 1105, and the systemprocess in the system/multiplex processing unit 1106, the packet isMPEG4-decoded in the MPEG4 audio processing unit 1107 and/or the MPEG4video processing unit 1108. The decoded data is then transferred to anapplication, for example.

In the example of FIG. 10, the error correction codes with differentlevels of correction capability are separately applied to the firstfragment 902 and the second and subsequent fragments 903-904. Takinginto account the above characteristic, however, an option ofretransmitting data with the function of the link layer if an erroroccurs may be selected for the second and subsequent fragments dependingon, for example, the attributes of data. One example of a scenariowhereby such an option is selected will be described below withreference to FIG. 11.

FIG. 11 shows one example of IP packets that are generally transferred,in which TCP is employed as the transport protocol. In an exemplaryembodiment, it is assumed that the H.245 negotiation (in FIG. 6) decideswhether the retransmit control that is to be carried out as the errorcontrol scheme in the link layer, when DATA2 corresponding to the Maxcode=2 is transferred. It is also assumed that the error control schemeis the same as described above in the case of the MUX code=1.

Based on those assumptions, as shown in FIG. 11, second and subsequentfragments 1103-1104 are transferred with the MUX code=2 set in the H.223header (the FEC code is not necessarily required}. Accordingly, if anerror occurs in the fragments (1006-1107) between the access router 103and the terminal 107 and is not completely corrected by the errorcorrection code (Golay parity), error control can be performed in such amanner as to invoke the retransmit control for an entire fragment.

On the other hand, the MUX code=1 and the FEC code=1 are set for thefirst fragment 1002, so that the error correction code FEC1 is appliedto the first fragment 1002 before transmitting the subsequent fragments.It is thus expected that any potential errors that may have occurred onthe radio transmission path 106 are substantially completely corrected.

The process on the receiving side is basically the same as in theexample of FIG. 10. In this example, however, when the MUX code=2 isdetected in the received frame, the receiving-side terminal can confirmthat the retransmit control is to be performed by referring to the MCtable 1114. Accordingly, upon the occurrence of an error, the errorcontrol is not performed, and the retransmit control is performed,unlike the example of FIG. 10. When the MUX code=2 is detected in thereceived frame, the frame is processed in the same manner as in theexample of FIG. 10. The above description has been made as applyingdifferent error corrections codes depending on fragments, which areprepared by dividing a particular packet.

In actual Internet communication, there are mixed packets having variousattributes. For example, the same radio terminal may transfer a file,while operating an MPEG4 application. Thus, a variety of situations,such as coexistence of TCP communication and UDP communication, mayoccur. Such a coexistence of differing packets can be dealt with, forexample, by carrying out error control based on the forward errorcorrection code, as shown in FIG. 9, when the packet is an MPEG4 packet(or a UDP packet), and carrying out error control based on theretransmit control, as shown in FIG. 11, when the packet is a TCPpacket.

The reasons for changing the error control scheme are discussed below.In the case of an MPEG4 packet, a retransmit control would not beeffective because of the time-sensitivity of the application; moreover,the MPEG4 data itself has error resistance. It is therefore sufficientto apply the “weak” error correction code to the MPEG4 packet. On theother hand, for the TCP packet, the payload is not expected to haveerror resistance, and thus, the retransmit control in the radiotransmission path 106 is appropriate, matching the characteristic of TCP(i.e., a delay in transmission gives rise no serious problem). Thus,there is a merit in changing the error control scheme depending on theattributes of a packet at the higher-level layer.

As a mechanism for implementing the above error control scheme, theflow/error control correspondence table 1117 is prepared in the frameprocessing unit 1112 as shown in FIG. 12, by way of example, to specifythe error control scheme to be employed for each higher-level layerprotocol of a passing packet, or for each passing IP flow (an arbitrarycombination of the source address, source port number, destinationaddress and destination port number, or an arbitrary combination ofthose items and the higher-level layer protocol). When transmitting apacket in the form of divided fragments to a network, one exemplarymethod involves the frame processing unit 1112 receiving the attributesof the packet (i.e., information regarding the higher-level layerprotocol or flow) from the fragment processing unit 1111, and decidingthe error control scheme to applied to each of the fragments byreferring to the flow/error control correspondence table 1117 of FIG. 12based on the received information. For example, whether the packet is aTCP flow or a UDP flow is determined by referring to the protocol typefield of the IP header. Then, the error control scheme to be applied toeach fragment (of the packet) is determined by referring to the table ofFIG. 12.

As mentioned earlier, when the protocol type field indicates the TCPprotocol, the error correction scheme FEC1 having a strong correctionability is employed for the first fragment and the relatively weak errorcorrection scheme FEC2 is employed for the second and subsequentfragments. On the other hand, when the protocol type field indicates theUDP protocol, the error correction scheme FEC1 with a strong correctionability is employed for the first fragment and the retransmit control isapplied to the second and subsequent fragments.

The error control scheme can be changed in various ways depending onwhich one of the attributes is to be taken into consideration. Turningto the above TCP example, in some of the packets with the TCP protocol,the payload has error resistance in itself. This characteristic of thepayload can be ascertained by checking the port number. Therefore, theerror control scheme may be changed depending on the port number (theprotocol type field and the port number).

While only the internal configuration of the terminal 107 has beendescribed, it is a evident that the access router 103 may also have asimilar internal configuration.

Further, the first embodiment has been described as allocating thepayload portion (MPEG4 video) to all the first to third fragments. It ishowever also possible to include only the header portion from the PPPheader to the system header, which are low in error resistance, in thefirst fragment, and to allocate the MPEG4 video portion having higherror resistance to the second and subsequent fragments.

The above first embodiment has been described as employing H.223 and ashaving an area of the FEC code in the H.223 header. In a secondembodiment described below, the area of the FEC code does not exist inthe H.223 header, and the type of the FEC code applied to a transmittedframe is implicitly contained in the MUX code (MC).

The network system configuration, the entire layer configuration, andthe transfer packet format for use in the second embodiment arebasically similar to those, shown in FIGS. 1 to 3, in the firstembodiment. The terminal internal configuration resembles theconfiguration shown in FIG. 4, except that, as will be described indetailed later, neither the FEC table 1113 nor the function to carry outthe processing related to the FEC table 1113 are required. Because ofthe many similarities between the first embodiment and the secondembodiment, only those aspects that differ will be discussed below.

FIG. 13 shows an example of a frame transmission format used over aradio transmission path, according to a second embodiment of the presentinvention. The frame transmission format differs from the format in thefirst embodiment, shown in FIG. 5, in that the FEC type code is omittedfrom the header.

FIG. 14 shows one example of an entire sequence of the negotiationbetween the access router 103 and the terminal 107 according to thesecond embodiment.

In the first embodiment, as shown in FIG. 6, the type of FEC to be usedand other information regarding data are negotiated using separate codes(i.e, the FEC code and the MC code). In this second embodiment, the FECcode is not used, and the value of the MC code, including the type ofFEC to be used, is decided during the H.245 negotiation (i.e., what thevalue of the MC code means is decided through the negotiation). In otherwords, the negotiation is performed such that both the transmitting andreceiving sides can recognize the type of FEC to be used from the MCvalue. Results of the negotiation are reflected in the MC table shownin, by way of example, in FIG. 15. The MC table is held in both nodes,i.e., the access router 103 and the terminal 107.

It is negotiated, for example, that in the case of MC=1 and MC=2, datathat have different attributes (DATA 1 for MC=1 and DATA 2 for MC=2) areexchanged, and that in the case of MC=1, FEC1 is used as the FEC schemeand in the case of MC=2, FEC2 is used as the FEC scheme, respectively.The results are then reflected in the MC table as shown in FIG. 15.

Additionally, as with the first embodiment, FEC1 represents a code witha correction ability capable of substantially completely correcting theerror rate of 10⁻³ on the radio transmission path, and FEC2 represents acode having a correction ability capable of reducing the error rate of10⁻³ on the radio transmission path down to a limit value of the errorresistance of MPEG4, i.e., the error rate of 10⁻⁶.

One example of a manner of transferring a MPEG4-over-IP packet will benext described with reference to FIG. 16. This manner differs from themanner in the first embodiment, shown in FIG. 9, in that the type of FECto be used can be ascertained from the MC value. More specifically, asshown at 1605 in FIG. 16, a first fragment 1602 is converted into aframe in accordance with H.223, and FEC1 is employed as the errorcorrection code for the first fragment 1602 because a strong errorcorrection code should be applied. Accordingly, the value of the MUXcode is set to 1 in the frame. The frame is then transmitted.

On the other hand, for second and subsequent fragments 1603-1604, FEC2is employed as the error correction code because the relatively weakerror correction code is sufficient to reduce the error rate down to alevel corresponding to the error resistance of MPEG4. Accordingly, thevalue of the MUX code is set to 2 in the frame; thereafter, the frame istransmitted.

The example of FIG. 16 has been described in connection with the case inwhich the payload of the IP packet is the data having error resistancesuch as MPEG4 data As with the first embodiment, however, the secondembodiment of the present invention has general applicability to thetransfer of IP packets regardless of the attributes of data contained inthe payload.

FIG. 17 shows an example of the general transfer of IP packets, in whichTCP is employed as the transport protocol, according to an embodiment ofthe present invention.

This example differs from the example of the first embodiment, shown inFIG. 10, in that the type of FEC to be used can be ascertained from theMC value in a similar fashion as the FIG. 16. In this case, as with thecase of FIG. 16, FEC1 (MC=1) is employed as the error correction codefor a first fragment 1702 because a strong error correction code shouldbe applied. On the other hand, second and subsequent fragments 1703 and1704 are transferred using the relatively weak error correction codeFEC2 (MC=2).

The above description has been made of the process executed when theterminal 107 is on the transmitting side. When the terminal 107 is onthe receiving side, the process is performed basically in a reversedmanner to the process on the transmitting side.

Assuming terminal 107 shown in FIG. 4 receive packets, a frame receivedby the radio interface unit 1116 in the H.223 mobile processing unit1101 is first subject to frame synchronization in the frame processingunit 1112.

Then, the FEC scheme to be employed is selected by referring to the MCtable 1114 based on the MC code in the received frame. Thereafter, theerror correction code is applied to each frame. In the example of FIG.15, when the MC code=1 holds in the received frame, it is understoodthat the FEC scheme to be employed is FEC1. The frame for which theerror correction has not been completely performed is discarded.

Having passed the error correction process, the fragments are taken outof the frame and are transferred to the fragment processing unit 1111,where the fragments are assembled to form the original packet. Thispacket is subject to the PPP process and IP process in the IP/PPPprocessing unit 1102. After successively passing the UDP process in theUDP processing unit 1104, the REP process in the RTP processing unit1105, and the system process in the system/multiplex processing unit1106, the packet is MPEG4-decoded in the MPEG4 audio processing unit1107 and/or the MPEG4 video processing unit 1108. The decoded data isthen transferred to an application, for example.

In this second embodiment, as with the first embodiment, the errorcontrol scheme may also be changed depending on the attributes of apacket at the higher-level layer, the port number, etc. As a mechanismfor implementing this process, the flow/error control correspondencetable 1117 is likewise prepared in the frame processing unit 1112 asshown in FIG. 12, by way of example, to specify the error control schemeto be employed for each higher-level layer protocol of a passing packet,or for each passing IP flow. When transmitting a packet in the form ofdivided fragments to a network, one exemplary method involves the frameprocessing unit 1112 receiving the attributes of the packet (i.e.,information regarding the higher-level layer protocol or flow; forexample, by referring to the protocol type field in the IP packet) fromthe fragment processing unit 1111, and deciding the error control schemeto applied to each of the fragments by referring to the flow/errorcontrol correspondence table 117 of FIG. 12 based on the receivedinformation.

While the internal configuration of the terminal 107 has been describedso far, it is apparent that the access router 103 may also have asimilar internal configuration.

While the embodiments have been described primarily in connection withthe case of transferring the MPEG4 video and the MPEG4 audio as dataobtained with the coding technique having high “error resistance”, thepresent invention is also applicable to the case of transferring dataobtained with any other coding technique having high “error resistance”.

It is to be noted that the functions described above can also berealized in the form of software.

Further, the embodiments can also be implemented in the form of acomputer-readable recording medium, which records thereon a program forrendering a computer to execute predetermined sequences (or rendering acomputer to function as predetermined means, or rendering a computer torealize predetermined functions).

The present invention is not limited to the above-described embodiments,but can be implemented in various modified forms without departing fromthe technical scope of the invention.

With the present invention, when a header portion and a payload portionof a packet to be transmitted have different error resistancecharacteristics, the packet can be transmitted to a network underselection of error correction schemes suitable for the respective errorresistance characteristics.

Obviously, numerous modifications and variations of the presentinvention are possible in light of the above teachings. It is thereforeto be understood that within the scope of the appended claims, theinvention may be practiced otherwise than as specifically describedherein.

1-15. (canceled)
 16. A method for transferring packet segments in aradio network, comprising: dividing a packet to be transmitted,including a header and a data part, into a plurality of packet segments,each packet segment including a segment header and data, being eitherone of a first packet segment which includes at leas a portion of theheader of the packet to be transmitted or a second packet segment whichincludes the data part of the packet to be transmitted; negotiating witha destination device which receives the packet segments, for selectingerror correction schemes for the first and second packet segments;carrying out an error correction process on each packet segment with theselected error correction scheme; and transmitting each error correctedpacket segment including an information on the selected error correctionschemes in the segment header to the destination device through theradio network, wherein an information of the selected error correctionscheme for the first packet segment is given a higher error correctionability than that is given to the second packet segment.
 17. A methodfor receiving packet segments from a radio network, comprising:negotiating in advance, with a source device which transmits packetsegments, for selecting error correction schemes for packet segments;receiving error corrected packet segments from a radio network, eachpacket segment including an information on selected one of the errorcorrection schemes in a segment header and transmitted from the sourcedevice, the packet segment being either one of a first packet segmenthaving a higher error correction ability or a second packet segmenthaving a lower error correction ability; carrying out an errorcorrection process on the packet segment with the selected errorcorrection schemes depending upon the information of the segment header;and reconstructing a packet from the plurality of packet segments afterthe error correction process, wherein the packet including a headerreconstructed from the first packet segments and a data part mostlyreconstructed from the second packet segments.